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ABSTRACT 

A  software  reuse  library  is  only  useful  if  the  assets  within  the  library  can  be  quickly 
and  easily  located,  evaluated,  and  the  characteristics  of  the  assets  be  easily  under¬ 
stood.  This  Command  Center  Supported  Components  Repot  provides  a  set  of 
guidelines,  initially  developed  for  Command  Center  Libraries,  to  assist  domain  en¬ 
gineers  and/or  the  qualification  team  in  charge  of  the  library  in  providing  informa¬ 
tion  on  domain-specific  qualified  library  assets.  These  guidelines  consist  of  one 
page  templates  describing  a  component  from  a  high  level  viewpoint,  i.e.,  “glossies”, 
and  a  multi-page  template  describing  a  component  in  greater  technical  detail,  i.e., 
“technical  brief”. 

Two  examples  of  a  glossy  and  technical  brief  are  provided  in  the  appendix. 
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Command  Center  Supported  Components  Report 
1  Introduction 

1.1  Overview 

This  report  describes  informational  and  technical  documents  intended  to  describe  qualified 
components  that  are  assets  within  a  domain-specific  reuse  library [7];  These  documents  are  in¬ 
tended  to  be  used  by  library  users  (engineering  personnel)  who  need  to  access  components 
stored  within  the  library  and  by  potential  component  providers.  Two  different  types  of  docu¬ 
ments  are  described:  “ glossies ”  and  “ technical  briefs ”.  The  purpose  of  this  document  is  to  de¬ 
scribe  what  information  these  reports  contain,  their  intended  use,  and  the  manner  in  which  they 
are  created.  Samples  of  these  reports  are  provided  for  illustrative  purposes. 

Glossies  are  single  page  documents  describing  a  component  within  a  domain-specific  library 
from  a  top-level  perspective.  The  technical  brief  is  a  multi-page  document  describing  the  com¬ 
ponent  in  greater  detail,  to  include  its  differences  relative  to  other  library  components,  and  the 
results  of  the  qualification  process  through  which  the  component  qualified  for  inclusion  in  the 
library.  Both  serve  as  an  application  guide  for  the  customer  of  the  library,  providing  informa¬ 
tion  on  “form,  fit,  and  function”  measures  of  compatibility  between  software  components  and 
the  system  or  domain  architecture.  Together  they  provide  the  library  user  a  mechanism  for 
identifying  “architecture-compliant”  components  for  building  a  system. 

Examples  of  specific  glossies  and  technical  briefs  are  provided  for  two  qualified  components 
stored  within  the  Central  Archive  for  Reusable  Defense  Software  (CARDS)  Command  Center 
Library  (CCL).  The  components  are  OILSTOCK,  a  high  resolution  interactive  graphics  sys¬ 
tem,  and  the  Software  Engineering  Institute’s  MTV,  a  message  translator  and  validator.  Al¬ 
though  these  examples  provided  are  specific  to  the  Command  Center  Domain,  the  details  for 
creation  of  glossies  and  technical  briefs  are  equally  applicable  to  any  domain. 

1.2  Audience 

This  Command  Center  Supported  Components  Report  is  intended  to  be  used  by  die  domain- 
engineers  and/or  qualification  team  (responsible  for  qualifying  components  into  a  domain  spe¬ 
cific  reuse  library)  for  preparing  glossies  and  technical  briefs  for  library  components.  The  qual¬ 
ification  team  in  collaboration  with  the  component  vendor  will  create  glossies  and  technical 
briefs  (or  modify  existing  information  provided  by  component  creators)  containing  domain- 
specific  qualification  information.  The  qualification  team  will  use  the  Product  Evaluation  Re¬ 
port  (PER),  a  by-product  of  the  component  qualification  process,  for  particular  products  to  aid 
in  completing  the  glossies  and  technical  briefs  [3].  The  vendor  may  also  use  the  PER  to  en¬ 
hance  future  versions  of  their  product  as  well  as  aid  in  preparing  the  information  they  provide 
for  the  glossy  and  technical  brief. 
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The  glossies  and  technical  briefs  will  be  used  by  engineers,  engineering  managers,  and  compo¬ 
nent  vendors  seeking  to  access  components  stored  within  a  domain-specific  model-based  reuse 
library  [4], 

1 J  Concept 

The  concept  guiding  the  development  of  both  templates  focuses  on  providing  the  library  user 
with  a  clearer  understanding  of  the  component — system — architecture — domain  relationship. 
Providing  the  library  user  with  a  medium  for  framing  the  relationship  of  a  component  to  a  par¬ 
ticular  domain  is  very  important  for  effectively  and  efficiendy  building  systems.  A  component 
fulfills  a  role  within  a  system  which  fulfills  a  role  within  an  architecture  and  ultimately  within 
a  domain.  These  roles  can  only  be  fulfilled  if  the  necessary  constraints  and  requirements  of  the 
domain  are  met.Clearly  communicating  these  constraints  and  requirements  via  supplementing 
library  services  is  a  main  objective  of  the  glossy  and  technical  brief  templates. 

A  closely  related  objective  of  the  glossy  and  technical  brief  templates  is  to  provide  a  vehicle 
for  components  to  be  advertised  or  marketf  j  to  library  users.  The  marketing  environment  in¬ 
troduced  by  the  glossies  and  technical  briefs  provides  a  motivation  for  future  growth  of  the  li¬ 
brary  because  component  providers  will  need  to  keep  their  products  up  to  date  and  competitive 
with  the  other  components  to  ensure  they  will  be  chosen  for  system  development. 

2  Background 

2.1  Component  Qualification  and  tiie  Model-Based  Approach  to  Reuse 

There  are  generally  two  approaches  to  implementing  a  reuse  libiury  [9].  One  is  a  comp  'nent- 
based  approach  and  the  other  is  a  model-based  approach.  Component-based  libraries  are  orga¬ 
nized  around  collections  of  reusable  components  (e.g.,  software,  documentation,  and  architec¬ 
tures).  While  component-based  libraries  can  support  reuse  of  a  broad-spectrum  of  component 
types,  the  underlying  operational  concept  is  that  of  search  and  retrieval  of  individual,  usually 
unrelated,  components.  When  components  are  inserted  into  these  librai  ies,  they  are  typically 
classified  in  broad,  generalized  categories;  information  describing  their  specific  role  in  a  par¬ 
ticular  problem-domain  architecture  is  not  formally  encoded.  For  example,  there  is  no  schema 
for  describing  the  effectiveness  or  efficiency  of  a  component  for  any  given  domain  (e.g.,  com¬ 
mand  center).  As  a  result,  information  about  domain-specific  usage  context  is  no  longer  at¬ 
tached  to  ihe  component  and  therefore  lost  to  the  reuser.  Advantages  of  a  component-based 
approach  include  strong  search  mechanisms  based  on  well-known  classification  techniques, 
the  ability  to  reuse  across  a  broad  range  of  application  areas  simultaneously,  and  scalability  of 
the  mechanism  to  very  large  component  populations. 

Model-based  libraries  use  domain  models  as  a  foundation  for  library  organization  and  a  frame¬ 
work  for  supporting  applications  which  exploit  these  models  to  automate  various  library  ser¬ 
vices.  The  library  model  encompasses  information  such  as  domain  knowledge,  generic 
architecture  specifications,  requirements,  implementation  restrictions,  as  well  as  software  arti- 
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facts  (including  oft-  the-shelf  products).  The  inclusion  of  this  additional  information  within  the 
library  model  supports  a  “components  in  —  subsystem  out'  paradigm  that  facilitates  the  con¬ 
cept  of  mega-program  mi  ^g  desired  by  the  Department  of  Defense  [8].  Advantages  of  t  model- 
based  approach  include  the  ability  to  provide  a  domain-context  for  components  and  support  for 
reuse-oriented  engineering  activities  (e.g.,  system  composition,  component  qualification).  Dis¬ 
advantages  include  weak  associative  search  and  retrieval,  a  lack  of  cross-domain  component 
search  and  retrieval,  and  relatively  small  component  population  resulting  from  a  narrow  do¬ 
main  focus. 

While  the  CARDS  Command  Center  I  ibrary  (CCL)  adheres  to  a  model-based  paradigm  in 
support  of  domain-specific  reuse,  the  nature  (as  illustrated  by  the  advantages  and  disadvantag¬ 
es)  of  the  approaches  suggest  that  they  are  not  diametrical,  but  rather  complementary  [9], 

In  summary,  CARDS  distinguishes  the  concept  >f  a  Component-based  library  from  a  Model- 
based  library  [7].  The  CARDS  model- based  approach,  uses  a  library  model  which  encodes  and 
describes  the  relationship  of  the  components  in  the  library  against  the  require  ments  and  con¬ 
straints  imposed  by  a  specific  application  domain  (e.g.,  command  center).  These  constraints 
form  an  evaluation  criteria  for  components  evaluated  for  inclusion  in  the  library.  The  glossy 
and  technical  brief  provide  user-friendly  marketing  information  on  the  results  of  the  compo¬ 
nent  qualification  process. 

2.2  Component  Qualification  and  Preferred  Products. 

The  content  described  in  the  glossy  and  the  technical  brief  is  supported  and  facilitated  by  the 
information  gathered  during  the  Component  Qualification  Process  [3]  [6].  Component  qualifi¬ 
cation  is  the  process  of  acquiring  and  evaluating  components  for  a  domain-specific  library.  The 
key  role  of  component  qualification  is  to  measure  the  “form,  fit,  and  function”  of  a  component 
against  the  constraints  inherent  within  the  architecture  for  that  domain.  Components  are  mea¬ 
sured  against  domain  and  common  metrics  in  the  evaluation  process.  Domain  requirements  are 
established  in  a  high-level  form,  for  example,  the  Portable,  Resuable,  Integrated  Software 
Modules  (PRISM)  program’s  command  center  prototype.  These  domain  requirements  are  then 
mapped  to  features  of  the  component  family  to  establish  a  set  of  component  constraints.  These 
component  constraints,  along  with  architectural  and  implementation  constraints,  make  up  the 
domain  metrics.  Common  metrics  are  criteria  used  to  evaluate  components  regardless  of  do¬ 
main.  Common  metrics  are  defined  based  on  categories  such  as  reliability,  maintainability, 
portability,  and  security.  Results  of  the  evaluation  process  will  be  available  to  users  and  may 
indicate  the  need  for  wrapper  software  to  fully  implement  the  requirements  of  the  domain. 

Commercial  software  certified  and  qualified  against  criteria  specific  to  a  domain  would  be  list¬ 
ed  as  products  or  components  which  have  been  distinguished  as  preferred  products  and  would 
be  considered  better  suited  for  systems  development  (relative  to  other  commercial  products 
which  have  not  been  pre-evaluated  for  systems  development)  in  that  domain. 
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The  glossy  and  technical  brief  templates  discussed  in  this  report  play  an  important  role  in  sup¬ 
porting  this  concept  by  providing  a  vehicle  to  “market”  CCL  architecture-compliant  compo¬ 
nents  (or  any  libraries  components  for  that  matter).  Other  reuse  libraries,  such  as  Defense 
Information  Systems  Agency/CIM’s  Defense  Software  Repository  System  (DISA/CIM’s 
DSRS)  [1]  and  the  Software  Technology  for  Adaptable,  Reliable  Software  Asset  Source  for 
Software  Engineering  Technology  (STARS  ASSET)  [5]  reuse  libraries  have  established  certi¬ 
fication  processes  which  play  an  important  role  in  this  vision. 

23  Identifying  Domain-Specific  Library  Components 

Once  a  contractor  is  chosen  to  devel op  a  system,  the  losing  bidders  proposed  system(s)  (and 
thus  proposed  components)  are  most  often  “shelved”.  Unique  and  valuable  ideas,  designs,  par¬ 
adigms,  or  actual  implementations  thus  may  not  be  utilized  because  they  are  “embedded”  in  the 
losing  system.  A  bidder  isoften  chosen  because  the  Government  decided  that  the  development 
proposal  and/or  approach  for  the  proposed  system  best  met  desired  constraints  and  goals  at  a 
system  level.  There  is  very  little  focus  on  whether  a  bidder  intended  to  use  newly  developed 
components  or  reuse  existing  components  in  the  bidding  process. 

The  reality  of  this  scenario  is  that  several  of  the  components  that  comprise  the  competing  sys¬ 
tems  may  serve  basically  the  same  functionality.  This  “reinventing  of  the  wheel”  can  mean  a 
significant  amount  of  time  and  money  being  wasted.  It  could  also  be  that  components  from  oth¬ 
er  previously  developed  or  proposed  systems  would  be  superior  to  comparable  components  in 
the  winning  bidders  system,  but  since  the  proposals  are  at  a  system  level  there  is  no  mechanism 
for  utilizing  or  evaluating  superior  components.  From  the  Government’s  perspective,  under 
this  scenario,  it  may  not  be  getting  the  optimal  systems. 

The  likelihood  that  a  large  percentage  of  the  components  in  the  desired  system  have  already 
been  produced  in  previous  systems  is  a  very  important  issue.  The  issue  must  be  addressed  by 
eliminating  this  unnecessary  duplication  and  waste  of  valuable  resources.  If  the  contractors 
could  have  chosen  from  a  library  of  components  or  systems,  tested  and  categorized  for  building 
systems  in  a  specific  domain  —  the  valuable  time,  money,  and  resources  could  have  been 
saved. 

The  Government  increasingly  requests  proposals  for  a  system  based  on  the  domain  architec- 
ture.Using  the  “Command  and  Control  (C2)  Store”  -  a  conceptual  model  for  developing  com¬ 
mand  centers,  as  a  basis,  components  are  evaluated  and  tested  to  be  compliant  with  the  domain 
architecture.  The  contractors  evaluate  components  for  building  the  system  by  consulting  a  do- 
main-specific  library.  Specific  components  can  be  evaluated  relative  to  system  requirements 
using  library  services,  i.e.,  browser  services.  During  this  evaluation  process  it  is  important  that 
components  can  be  easily  and  efficiently  identified  and  analyzed.  The  standard  formats  for  the 
technical  briefs  and  glossies  used  in  conjunction  with  other  library  services  (on-line  or  in  hard¬ 
copy)  provide  a  familiar  and  easy  to  follow  resource  for  evaluating  components  and  fulfilling 
this  requirement. 
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In  other  words,  a  significar  t  percentage  of  a  proposed  system  will  be  comprised  of  existing 
components  and  subsystems  identified  via  a  domain-specific  library.  This  identification  pro¬ 
cess  is  very  important.  A  domain-specific  library  may  have  many  valuable  resources,  but  if 
they  can  not  be  identified  and  extracted  with  the  least  amount  of  effort  the  maximum  intended 
benefits  can  not  be  realized.  The  contractor  must  have  a  sound  and  effective  interface  or  “com¬ 
munication”  mechanism  with  the  domain-specific  library  to  effectively  identify  components 
for  system  development.  Competing  contractors  can  then  be  evaluated  by  how  they  assemble 
existing  off-the-shelf  qualified  components  and  by  their  designs  for  the  customized  percentage 
of  the  system  that  could  not  be  developed  with  existing  components. 

If  a  contractor  has  a  component  or  a  plan  for  the  implementation  of  a  component  that  outper¬ 
forms  existing  components,  either  that  component  can  be  submitted  for  qualification  or  the  plan 
for  development  of  the  component  can  be  submitted  as  part  of  the  proposal.  To  further  expand, 
if  a  new  version  of  a  component  has  been  developed  from  an  existing  qualified  component  or 
from  an  unqualified  component,  the  new  version  would  need  to  be  (re)qualified  based  on  the 
added  or  modified  functionalities.  This  process  lessens  the  danger  of  impeding  the  develop¬ 
ment  of  newer  and  better  components  and  subsystems. 

The  results  are  a  cost  effective  proposal  and  an  evaluation  process  which  saves  money  and  time 
in  terms  of  proposal  preparation.  The  Government  can  be  assured  that  the  majority  of  the  com¬ 
ponents  labeled  in  the  system  are  the  “best”  available.  In  addition,  less  money  and  time  will 
have  to  be  expended  in  acquiring  the  desired  system.  The  Government  can  then  focus  on  eval¬ 
uating  the  customizations  proposed  by  each  contractor  which  will  be  significantly  smaller  than 
evaluating  a  complete  system  proposal. 

The  concept  described  above  may  leave  one  important  issue  unclear.  How  do  we  maintain  the 
originality  and  creativity  needed  to  incorporate  innovation  and  growth  into  future  applications 
in  the  domain?  It  must  be  understood  that  this  scenario  does  not  forbid  the  improvement  of 
existing  systems.  Nor  does  it  limit  the  variation  of  a  particular  component.  Since  the  nature  of 
the  new  component  acquisition  process  moves  the  focus  to  the  component  level,  vendors  of  a 
particular  component  will  need  to  continually  maintain  and  improve  the  component  or  it  will 
not  be  used  in  future  system  development. 

2.4  Distribution  and  Modification  Limitations/Restrictions 

Each  of  the  levels  of  rights  associated  with  components  or  subsystems  requires  the  software  or 
technical  data  to  be  marked  in  a  certain  way  and  may  also  have  certain  use,  distribution,  and 
modification  limitations/restrictions  .The  Government  has  either:  unlimited,  restricted,  limited, 
or  Government  Purpose  License  Rights  (GPLR),  (depending  on  what  was  negotiated  in  the 
original  contract  with  the  contractor)  rights  over  the  custom  software  systems  it  contracts  for 
development  (namely,  govemment-of-the-shelf  (GOTS))[2],  This  type  of  information  is  very 
important  when  identifying  components  for  development.  A  domain-specific  library  providing 
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components  for  system  development  must  ensure  that  the  library  user  can  accurately  identify  any 
and  all  restrictions  associated  with  a  particular  library  asset. 

Commercial-of-the-shelf  (COTS)  software  also  has  defined  restrictions.  Ownership  remains  with 
the  commercial  vendor  and  specific  agreements  concerning  usage  and  licensing  are  established. 
The  commercial  vendor  may  need  to  implement  modifications  to  the  component(s)  to  meet  domain 
criteria  and  keep  the  component  up  to  par  with  qualification  standards.  The  commercial  vendor  as¬ 
sists  library  maintained  in  preparing  glossies  and  technical  briefs  based  on  the  component  evalu¬ 
ation.  If  the  vendor  for  whatever  reason  does  not  make  required  modifications,  the  component  may 
not  be  eligible  for  use  in  system  development.  This  introduces  an  element  of  competitive  leverage 
to  the  process.  Which  in  turn  provides  the  stimulation  for  maintaining  quality  components. 

2.5  GOTS,  COTS,  and  Public  Domain  relationships 

The  preferred  product  provider,  i.e.,  commercial  vendor,  has  a  very  unique  opportunity.  In  an  ac¬ 
quisition  process,  which  focuses  on  acquiring  discrete  software  components  instead  of  complete 
systems,  a  particular  commercial  component  vendor  is  now  presented  with  a  marketing  mechanism 
for  a  product  (e.g..  Command  Center  Library).  In  the  spirit  of  a  “Preferred  Product  Vision”,  a  list 
is  provided  of  components  readily  available  for  building  software  systems;  allowing  smoother  se¬ 
lection  and  providing  justification  for  use  of  COTS  (or  GOTS)  software.  At  the  same  time  the  Gov¬ 
ernment  is  reducing  risk  and  costs  of  systems  development. 

Currently,  public  domain  software  is  usually  available  “as  is”.  It  is  often  the  case  that  there  is  no 
way  to  indicate  the  level  of  quality,  and  thus  the  ease  of  maintenance  and  reliability.  This  often 
means  a  lot  of  time  and  resources  in  debugging  and  identifying  necessary  modifications  to  meet 
the  needs  of  the  intended  system.  The  important  point  with  public  domain  software  is  that  once  it 
has  been  certified,  qualified,  and  placed  in  a  library,  it  can  be  extracted  without  unnecessary  and 
time  consuming  work  to  bring  it  up  to  standard. 

Another  important  point  is  that  just  because  a  component  may  be  Public  Domain  does  not  neces¬ 
sarily  give  the  user  the  right  to  modify  the  code.  Public  Domain  software  can  carry  restrictions  and 
limitations  on  distribution,  use,  and  modifications  [2].  Public  Domain  software  is  not  usually  sold, 
so  there  are  no  distributors  or  retailers.  They  are  usually  found  by  word  of  mouth  or  on  public  bul¬ 
letin  boards. 

Once  a  public  domain  application  has  been  certified  (e.g.,  ASSET  certification  process  [6])  and 
then  qualified  through  the  component  qualification  process  (and  a  glossy  and  technical  brief  are 
prepared),  the  system  developer  can  proceed  with  more  confidence  in  the  component. 

Whether  the  component  is  COTS,  GOTS,  or  Public  Domain,  the  library  main  tain  ers  will  perform 
an  analysis  of  the  components  architecture  compliance  to  determine  the  degree  to  which  it  meets 
the  requirements  and  constraints  of  the  intended  mission  area  (e.g.,  command  center).  If  the  com¬ 
ponents  meet  the  criteria  (at  least  with  allowable  modification,  i.e.,  wrappers),  they  become  a  qual¬ 
ified  component  of  the  library.  There  may  also  may  circumstances  in  which  components  are 
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excepted  from  other  programs  performing  domain  specific  work  (e.g.  PRISM).  A  glossy  and 
technical  brief  would  then  be  prepared  for  the  component  to  be  used  as  an  aid  in  the  application 
development  and  component  acquisition  processes. 

3  Developing  a  Glossy 

A  library  component  glossy  provides  a  standardized  format  for  the  library  user  to  easily  gain 
information  about  a  particular  component.  The  library  services  provide  the  ability  for  the  user 
to  quickly  identify  the  components  applicability  to  their  system  design.  The  information  pro¬ 
vided  by  die  glossy  enhances  this  ability.  It  provides  a  platform  for  advertising  the  components 
capabilities  within  the  specific  domain  to  the  library  users  as  they  browse  the  library  or  by 
printing  hardcopies  at  a  workshop,  conference,  or  related  event.  The  glossy  may  be  accessed 
on-line  via  the  library. 

The  realization  of  these  abilities  require  glossy  support  of  the  following  four  uses  or  purposes: 

1.  Serve  as  a  vehicle  for  communicating  the  major  characteristics  of  domain- 
compliant  components. 

2.  Provide  a  high  level  summary  of  the  component  qualification  results. 

3.  Provide  summary  of  technical  details. 

4.  Support  evolution  of  the  library  (e.g.,  preferred  products  list). 

The  glossy  has  a  simple  format  intended  to  convey  the  appropriate  amount  of  information  need¬ 
ed  for  advertising  the  component  without  going  into  technical  specifics.  More  technical  details 
can  be  provided  in  the  technical  brief.  It  is  recommended  that  the  technical  brief  be  completed 
first,  then  appropriate  information  can  be  extracted  to  complete  the  glossy.  In  so  far  as  content, 
the  glossy  can  be  viewed  as  a  subset  of  the  technical  brief.  The  main  difference  being  that  the 
audience  viewing  the  glossy  will  probably  be  more  concerned  with  a  quick  and  easy  to  follow 
evaluation.  Once  the  glossy  has  been  used  to  identify  a  particular  component  more  detailed  in¬ 
formation  can  be  extracted  from  the  technical  brief.  The  template  for  the  physical  arrangement 
of  the  glossy  can  be  found  in  Figure  4-1.  As  can  be  seen  in  Figure  4-1,  the  glossy  should  cover 
the  following  areas: 

1 .  Role  within  the  Domain 

2.  Salient  Features 

3.  Technical  Specifications 

4.  Support 

5.  Licensing  and  Availability 

The  content  of  the  glossy  information  should  be  equivalent  to  one  page  (maximum),  front  and 
back.  Each  section  should  clearly  present  information  to  the  customer. 
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3.1  Role  within  the  Domain 

The  information  to  convey  in  this  section  should  answer  “What  is  the  function  of  this  compo¬ 
nent  within  a  specific  domain?”  Basically  this  section  should  be  based  on  the  executive  sum¬ 
mary  from  the  Component  Evaluation  [3]. 

3.2  Salient  Features 

This  section  should  clearly  define  “What  distinguishes  the  component  from  other  components 
filling  the  same  role  within  the  domain?”. 

33  Technical  Specifications 

Define  technical  requirements  that  must  be  met  for  this  component.  Answering  this  question 
would  involve  a  brief  description  of  hardware  and  software  requirements. 

3.4  Support 

Outline  who  currently  supports  this  component.  What  are  some  points  of  contact  for  the  com¬ 
ponent? 

3.5  Licensing  and  Availability 

Give  licensing  information  involved  with  utilizing  the  component.  What  costs  will  be  in¬ 
volved?  What  are  the  options  for  quantity  of  license  (e.g.,  single  or  multiple  user)?  The  infor¬ 
mation  should  include:  intellectual  property  (who  holds  copyright,  patent  or  trade  secret  and 
when  was  it  issued),  level  of  rights  for  the  Government  funded  components  (unlimited,  limited, 
restricted,  or  Government  Purpose  License  Rights),  and  associated  limitations  and/or  restric¬ 
tions  on  distribution,  and  modifications. 

The  Command  Center  Library  has  the  legal  obligation  to  supply  information  on  intellectual 
property  (i.e.,  patents,  copyrights,  trade  secrets,  and  associated  restrictions/limitations  on  use, 
distribution,  and  modification).  By  including  this  information  in  the  glossy  (as  well  as  the  tech¬ 
nical  brief)  the  library  user  can  see  it  when  accessing  components  while  browsing  the  library. 
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Role  within  the  <fill-in>  Domain 


Figure 


Salient  Features 


Function  within  the  specific  domain? 
What  is  the  CCL  view? 

Is  a  demonstration  available? 


Figure 

Technical  Specifications 


What  distinguishes  this  component 
from  other  components  that  fill  the 
same  role  within  the  domain? 


Support 

Technical  requirements? 
Hardware/Software  requirements? 

Point  of  contact? 

Who  supports  it? 

Licensing  and  Availability 

License  and  cost? 

Single  or  multiple  users? 

Figure  3-1.  Glossy  template 
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4  Developing  a  Technical  Brief 

The  purpose  of  the  technical  brief  is  to  provide  a  potential  developer  with  a  detailed  description 
of  a  component  in  terms  of  a  particular  domain  or  set  of  applicable  domains.  The  technical  brief 
is  an  extension  of  the  glossy.  It  covers  the  same  information  as  the  glossy  only  in  much  greater 
detail.  The  layout  of  the  technical  brief  should  be  as  follows: 

1.  Introducticn/Overview 

2.  Detailed  Functional  Description 

3.  Specific  Functions  within  the  Domain 

4.  Description  of  the  Salient  Features  of  the  Component 

5.  Support/Maintenance  information 

This  layout  is  similar  to  the  glossy  layout  because  the  technical  brief  expands  upon  the  infor¬ 
mation  in  the  glossy.  An  example  of  the  technical  brief  can  be  found  in  the  Appendix  B.  Figure 
5-1  presents  an  example  of  the  technical  brief  cover  page. 

4.1  Introduction/Overview 

The  overview  section  should  answer  the  basic  questions,  “What  is  the  component?”  ‘Where 
did  the  component  originate  from?”  The  functionality  should  also  be  described,  but  briefly  and 
clearly  enough  to  be  quickly  understood  and  provide  an  introduction.  In  general,  it  should  pro¬ 
vide  a  functional  overview.  Appropriate  application  areas,  limitations,  and  a  discussion  of  the 
interface  mechanisms  should  also  be  included  in  this  overview. 

4.1.1  Application  Area 

Describe  the  application  areas  within  the  domain  for  which  the  component  was  originally  de¬ 
veloped.  List  possible  variations  or  alternate  usage  for  the  component 

4.1.2  Limitations 

Describe  known  limitations  of  the  component  within  the  domain.  Describe  special  circum¬ 
stances  in  which  the  component  may  not  perform  as  described  in  the  functional  description. 

4.2  Detailed  Functional  Description 

This  section  of  the  technical  brief  should  provide  a  sufficiently  in-depth  discussion  of  the  func¬ 
tionality  of  the  component.  The  term  “sufficiently”  is  used  because  the  intent  of  the  technical 
brief  is  to  provide  information  about  the  component  in  terms  of  the  particular  domain.  A  fine 
granular  description  of  the  component  can  be  found  in  the  technical  documentation  for  the 
component  and  references  to  these  technical  documents  should  be  included.  Information  for 
this  section  should  come  from  at  least  the  following  areas  (as  appropriate): 
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1 .  Interface  functionality  (e.g.,  signal  or  interrupt) 

Interface  communications  (e.g..  name,  type,  scope,  use,  range,  etc.) 

Effects  of  a  call  to  the  interface  (i.e.,  describe  as  well  as  possible,  refer  to 
technical  documentation  for  the  component) 

2.  Memory  management 

3.  Return  values  (e.g.,  type,  description) 

4.  Side  effects 

5.  Error  handling 

6.  Dependencies  (i.e.,  sequences  that  must  be  followed) 

7.  External  subprogram  calls  and  parameters 

8.  Areas  of  special  attention  (i.e.,  suggestions  for  future  development) 

9.  Instantiation  and  Integration  instructions 

10.  Testing/debugging  instructions 

43  Specific  Functions  within  the  Domain(s) 

This  section  should  contain  information  about  the  specific  function  that  the  component  serves 
relative  to  the  domain  (or  domains)  in  which  it  is  applicable.  It  is  very  important  that  this  sec¬ 
tion  be  clear  because  it  is  possible  that  a  particular  component  may  be  capable  of  serving  mul¬ 
tiple  purposes  within  a  domain.  If  this  is  the  case  the  discussion  for  each  role  should  be  kept 
separate  and  distinguishable.The  description  of  the  roles  do  not  need  separate  technical  briefs, 
but  should  be  clearly  labeled  within  the  subsection  of  the  technical  brief. 

A  component  is  qualified  against  the  features  and  functionality  required  of  it  for  inclusion  in 
the  domain  for  which  it  is  being  evaluated.  This  set  of  required  functionalities  for  the  domain 
is  used  during  the  component  qualification  process  to  determine  if  the  functionalities  (or  a  sub¬ 
set  thereof)  qualifies  it  for  one  or  more  purposes  within  the  domain.  This  implies  that  the  com¬ 
ponent  may  have  multiple  sets  of  functionalities,  fulfilling  separate  roles,  for  the  domain  in 
which  it  is  being  qualified.  This  “multi-set  concept”  obviously  applies  to  different  domains.  For 
instance,  a  data  base  management  system  (DBMS)  may  be  qualified  for  the  command  center 
domain  because  it  has  specific  functionality  defined  by  functionality  set  A.  But,  for  the  domain 

of  say  intelligence,  that  same  DBMS  may  be  qualified  because  it  has  specific  functionality  de- 
* 

fined  by  functionality  set  B .  Sets  A  and  B  may  have  an  intersecting  subset,  but  may  not  be  prop¬ 
er  subsets.  It  is  these  clearly  defined  sets  that  reflect  the  differing  requirements  for  each  of  the 
respective  domains  (i.e.,  set  A  for  command  centers  and  set  B  for  intelligence).  It  is  the  goal  of 
this  section  to  convey  those  requirement  sets  that  are  satisfied  —  in  a  clear  and  distinguishable 
manner. 

The  functionality  of  a  component  and  its  relationship  to  the  domain  are  best  described  in 
the  component  class  (e.g.,  SYBASE  and  INGRES  are  components  that  are  “instances”  of  a 
DBMS  in  the  context  of  the  command  center  domain  [3]).  For  any  component  in  the  command 
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center  domain,  the  component  must  have  met  the  criteria  established  for  it  in  its  component 
class  (e.g.,  DBMS)  before  it  could  have  been  accepted.  To  “generically”  look  at  the  specific 
functions  of  a  component  in  a  domain,  look  to  the  definition  of  the  component  class  in  that  do¬ 
main.  From  the  component  class  you  can  trace  back  to  the  requirements  for  a  specific  compo¬ 
nent  feature  defined  in  that  component  class  (e.g.,  “the  ability  to  specify  queries  utilizing  ANSI 
SQL”  is  a  feature  of  the  component  class  of  DBMS).  To  “specifically”  see  if  a  particular  in¬ 
stance  of  a  component  class  (e.g.,  SYBASE)  satisfies  or  is  qualified  for  some  feature  of  that 
component  class,  trace  the  requirements  of  that  instance  within  the  component  class  (e.g.,  does 
SYBASE  have  the  “ability  to  specify  queries  utilizing  ANSI  SQL”). 

With  this  in  mind,  here  are  some  questions  to  be  answered  when  completing  this  section  of  the 
technical  brief  (note:  These  are  not  all  inclusive.): 

What  function  or  feature  set  is  required  of  the  component  for  the  particular 
domain? 

Are  there  multiple  function/feature  sets  for  this  component  in  this  domain? 

What  are  the  other  domains  in  which  the  component  is  qualified? 

What  features  are  optional  for  the  component  for  the  particular  domain? 

What  requirements  “lead*  to  those  required  component  features? 

4.4  Description  of  the  Salient  Features  of  the  Component 

This  section  defines  the  uniqueness  of  the  component  compared  to  other  components  that  fulfill 
the  same  role  within  the  domain.  What  features  of  a  specific  component  are  discriminators  with 
which  one  might  electively  choose  one  component  over  another  (e.g.,  if  SYBASE  and  INGRES 
are  equally  qualified  —  why  would  SYBASE  be  chosen  over  INGRES?)?  These  are  some 
questions  that  should  be  answered  when  completing  this  section: 

what  does  the  component  do  that  nobody  else’s  does? 

what  does  the  component  do  better  than  anyone  else’s  component? 

what  should  prospective  customer’s  remember  about  the  product? 

4.5  Technical  Specifications,  Support,  and  Maintenance  information 

Provide  information  detailing  how  to  contact  support  personnel  concerning  questions  related 
to  the  component.  You  should  provide  a  separate  section  in  the  technical  brief  for  each  of  these 
items.  This  information  should  include:  names,  telephone  numbers,  conventional  mail  ad¬ 
dresses,  and  email  addresses.  In  addition,  if  possible,  include  hours,  a  fax  number,  and  alternate 
electronic  service  addresses  (e.g.,  CompuServe).  Other  important  information  includes  consult¬ 
ing  and  training  information,  licensing  information,  and  ordering  information. 
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4.6  Licensing  and  Availability 

The  information  found  in  this  section  of  the  technical  brief  should  cover  basically  the  same  in¬ 
formation  found  in  the  corresponding  section  of  the  glossy. 

The  information  should  include:  intellectual  property  (who  holds  copyright,  patent  or  trade  se¬ 
cret  and  when  was  it  issued),  level  of  rights  for  the  Government  funded  components  (unlimited, 
limited,  restricted,  or  Government  Purpose  License  Rights),  and  associated  limitations  and/or 
restrictions  on  distribution,  and  modifications. 

The  Command  Center  Library  has  the  legal  obligation  to  supply  information  on  intellectual 
property  (i.e.,  patents,  copyrights,  trade  secrets,  and  associated  restrictions/limitations  on  use, 
distribution,  and  modification).  By  including  this  information  in  the  glossy  (as  well  as  the  tech¬ 
nical  brief)  the  library  user  can  see  it  when  accessing  components  while  browsing  the  library. 

5  Summary 

This  report  has  described  informational  and  technical  documents  for  describing  qualified  com¬ 
ponents  that  are  assets  within  a  domain-specific  reuse  library.  The  glossy  is  a  document  intend¬ 
ed  to  quickly  provide  a  summation  of  various  features  of  a  component  relative  to  a  domain- 
specific  library.  The  technical  brief  is  an  extension  of  the  glossy  providing  basically  the  same 
information  in  greater  detail.  These  documents  are  very  important  because  they  are  basic  ele¬ 
ments  in  building  a  marketing  strategy  for  supporting  domain-specific  library  components.  By 
following  the  standard  formats  outlined  in  this  report,  components  are  presented  to  library  users 
in  an  easily  recognizable  format 
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Figure  Shi.  Cover  for  Technical  Brief 
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APPENDIX  A:  Glossy  examples 

The  following  glossies  are  for  demonstration  purposes  only.  No  claim  is  made 
as  to  the  accuracy  of  the  content.  The  focus  is  intended  to  be  on  the  format  and 
structure. 


ROLE  WITHIN  THE  DOMAIN 

The  Software  Engineering  Institute  Message  Translation  and  Validation  (SEI  MTV)  system  is  a 
general  model  solution  written  in  Ada,  that  can  be  used  in  a  system  when  the  system  must  convert 
between  different  representations  of  a  message.  These  message  representations  can  be  character- 
based,  bit-based,  and  internal. 

MTV  was  written  specifically  for  the  Command,  Control,  Communications,  and  Intelligence 
domain  where  there  is  a  need  to  translate  and  validate  incoming  and  outgoing  messages. 

MTV  consists  of  two  parts,  the  first  of  which,  termed  the  model  solution,  deals  with  templates  and 
utilities  supplied  by  the  SF~.  These  are  used  to  produce  packages  called  field  and  record 
typecasters  and  the  definition  of  an  external  representation  of  ihe  message  called  Interface  Control 
Document  (ICD).  All  the  messages  produced  here  are  Ada  reusable  code.  The  second  part  of  the 
MTV  process  takes  these  models  and  joins  them  together  for  a  particular  message  type.  This  is  an 
Ada  package  linked  with  the  components  produced  above  to  execute  the  translation  and  validation 
of  a  message. 


SALIENT  FEATURES 

Developers  in  other  domains  where  a  need  to  translate  and  validate  messages  exists,  can 
understand  and  use  the  MTV  model  solution. 

There  is  one  version  of  MTV  which  handles  either  character  or  bit  based  messages,  based  on  user 
input  at  the  time  the  component  is  launched. 

The  MTV  will  perform  its  functions  in  real  time,  keeping  up  with  the  input  message  traffic.  Based 
on  typical  command  center  requirements,  MTV  will  handle  at  least  300  messages  per  minute  on  a 
20  MIP  workstation  The  number  of  fields  in  the  messages  and  whether  they  are  character  or  bit 
based  will  influence  the  message  throughput  Based  on  typical  message  complexity,  MTV  will 
handle  the  above  message  rate  for  either  character  or  bit  based  messages  for  messages  with  at  least 
15  fields. 

The  SEI  MTV  has  been  used  successfully  by  the  USAF  program  Granite  Sentry  for  character 
based  messages. 
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TECHNICAL  SPECIFICATIONS 

Currently  includes  message  typecasters  for  the  bit_based  message:  Surveillance 
The  PRISM  version  of  MTV  includes  message  TVpecasters  for  these  ASCII  messages:  e3a;  NUDET, 
Intercepter,  170  ROCC/SOCC  The  April  MTV  component  was  written  partly  in  C  and  included 
Sybase  specific  SQL  commands.  It  was  then  converted  entirely  to  Ada,  and  the  Sybase-specific  SQL 
converted  to  ANSI  SQL.  This  SQL  translation  required  the  development  of  the  Database  Broker 
component.  MTV  includes  the  typec asters  and  ICD  generated  from  the  SEI  MTV  templates  and 
support  software,  and  wrapper  software  written  for  PRiSM.  The  wrapper  software  includes  interface 
software  to  DECMess^geQ  (DMQ),  SQL  generation  software,  and  the  interface  to  the  Database 
Broker. 

The  SET  MTV  is  written  in  Ada  and  contains  no  proprietary  products.  It  was  developed  and  tested  on 
DEC/VMS  with  the  intent  that  it  could  run  on  any  platform.  However,  integration  testing  showed  that 
some  of  its  functionality  had  machine  and  compiler  dependencies. 


SUPPORT 

Software  produced  by  PRISM  program  at  Electronic  Systems  CenterfESC),  Systems  and  Software 
Design  Center  (AVS) 

CapL  Paul  Valdez,  PRISM  Deputy  Program  Manager:  (617)  377-3458 

PRISM 

ESC/AVSF 

Hanscom  AFB,  MA  01731-2116 


LICENSING  AND  AVAILABILITY 

The  SEI  MTV  product  was  written  by  the  Software  Engineering  Institute  (SEI).  It  is  government  off- 
the-shelf  software  and  does  not  require  a  license. 


ROLE  WITHIN  THE  DOMAIN 

Oil  stock  is  designed  to  track  airborne  targets,  including  aircraft,  satellites,  and  sea  going  vessels.  In 
addition  to  data  display,  analysts  can  draw  geopositional  overlays  on  OILSTOCK  maps  to  produce 
reports  or  amplify  information.  OILSTOCK  uses  the  CIA  World  Database  D  (WDBII)  as  its 
foundation  for  vector  maps  and  the  Defense  Mapping  Agency’s  ARC  Digitized  Raster  Graphics  for 
high  quality  raster  maps.  OILSTOCK  reads  Digital  Terrain  Elevation  Data  to  conduct  a  visual  line  of 
site  analysis. 

Advanced  features  include  ELINT/Direction  Finding  capabilities  and  calculating  satellite 
footprints.OILSTOCK  also  supports  cartographic  overlays  and  numerous  map  projections. 
OILSTOCK  reads  data  from  a  large  number  of  data  formats,  including  the  CIA  World  Data  Bank  n 
(WDBII)  and  Digital  Mapping  Agency  (DMA)  digital  maps. 


SALIENT  FEATURES 

OILSTOCK  is  a  stand-alone  Geographic  Information  System  (GIS)  application  with  features  that  are 
present  to  better  visualize  and  evaluate  plots,  including  placement  of  icons,  range  rings,  etc.  onto  a 
sketch  pad  which  can  be  saved  to  a  cartographic  overlay,  and  draped  over  various  map  projections. 
OILSTOCK  provides  a  mapping  system  application  with  support  for  analysis  of  target  plotting.  It  is 
easily  installed  and  evaluated  with  the  help  of  well  written  manuals. 

The  various  map  projections  supported  by  OILSTOCK  allow  numerous  views  of  plotted  data.  The 
icons  are  already  defined  when  delivered.  Incorporation  of  new  databases  is  described  fully  in  the 
Oil  stock  Installation  Guide  and  seems  to  be  relatively  uncomplicated. 


TECHNICAL  SPECIFICATIONS 

OILSTOCK  was  developed  in  C  on  a  System  V  UNIX  machine,  using  X  windows  for  display.  It  has 
been  successfully  compiled  on  the  following  platforms:  Sun3,  Sun4,  Masscomp,  Apollo,  HP  720, 
Silicon  Graphics,  DEC,  IBM  RS/6000,  and  Data  General  workstations. 
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SUFEQRI 

Support  is  available  from  NSA  via  U.S.  mail  and  a  toll  phone  number: 
The  National  Security  Agency,  J333 
9800  Savage  Rd. 

Fort  George  G.  Mead,  MD  20755 
(301)  688-5564 

OILSTOCK  is  accompanied  by  excellent  hard-copy  manuals. 


LICENSING  AND  AVAILABILITY 

OILSTOCK  has  been  released  to  the  CARDS  Program  for  Official  Use  Only  (FOUO)  by  the  National 
Security  Agency  (NSA). OILSTOCK  has  also  been  released  to  a  number  of  other  government 
agencies  and  contractors  under  the  same  restrictions. 
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APPENDIX  B:  Technical  Briefs 

The  following  technical  briefs  are  fa-  demonstration  purposes  only.  No  claim 
is  made  as  to  the  accuracy  of  the  content.  The  focus  is  intended  to  be  on  the 
format  and  structure. 
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The  Message  Translation  and  Validation  process,  MTV,  consists  of  two  parts,  the  first  of  which,  termed  the 
model  solution,  is  comprised  of  templates  and  utilities  supplied  by  the  Software  Engineering  Institute 
(SEI).  These  are  used  to  produce  packages  called  field  and  record  typecasters,  and  the  definition  of  an 
external  representation  of  the  message  called  the  Interface  Control  Document,  ICD,  which  is  the  second 
part  of  the  MTV. 

The  “item”  described  above  is  called  the  validatory  package.  All  of  the  modules  produced  here  are  Ada  re¬ 
usable  code.  This  pan  of  the  MTV  process  takes  these  modules  and  joins  them  together  for  a  particular 
message  type.  This  is  an  Ada  package  linked  with  the  components  produced  above  to  execute  the 
translation  and  validation  of  a  message.  It  contains  the  executive  gcc_validate  and  its  supporting  functions 
and  procedures.  It  is  called  by  the  System  manager,  gcc_sysmgr,  to  execute  the  translation  and  validation 
of  an  incoming  message.  All  the  record  typecasters  and  ICDs  for  the  message  types  supported  are  linked 
into  the  gcc.validate  procedure.  This  module  brings  together  the  two  SEI  solutions  produced  above  for  a 
particular  message  type,  the  record  typecasters  and  the  ICD.  The  translation  and  validation  of  a  message 
consists  of  a  transformation  from  an  input  ASCII  string  with  field  separators  to  a  byte  array  internal  image. 
Then  this  array  becomes  an  Ada  enumeration  where,  for  example,  the  input  character  ‘H’  of  a  track  class 
field  has  been  transformed  to  its  expanded  equivalent  ‘HOSTILE’.  Finally,  the  enumeration  image  is 
transformed  into  the  result  user  representation,  an  ASCII  character  string  describing  the  expanded  input 
message.  These  image  transformations  are  accomplished  through  three  function  calls:  one  in  the  ICD  to 
extract  the  first  image;  two  in  the  record  typecasters  to  achieve  the  result  string  thus  the  typecasters,  the 
ICD;  and  the  executive  are  joined.  The  result  string  is  then  parsed  onto  a  SQL  command  line  for  insert  The 
client  module,  gcc_sysmgr  is  then  called  to  access  the  SQL  server  to  store  translated  messages  in  the  actual 
or  exercise  database.  The  MTV  component  performs  the  translation  and  validation  of  both  characters  and 
bit  based  messages  and  the  update  of  the  mission  database  the  mission  application  displays. 

Limitations 

The  executive  is  coded  manually  but  a  template  can  be  made  in  the  future  to  facilitate  its  coding 
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SEI  MTV  is  a  model  that  is  a  general  solution,  written  in  Ada,  that  can  be  used  in  a  system  where  the 
system  must  convert  between  different  representations  of  a  message.  These  message  representations  can  be 
character-based,  bit-based,  and  internal.  MTV  was  written  specifically  for  the  Command,  Control, 
Communications,  and  Intelligence  domain  where  there  is  a  need  to  translate  and  validate  incoming  and 
outgoing  messages. 

The  MTV  consists  of  two  parts,  the  first  of  which,  termed  the  model  solution  deals  with  templates  and 
utilities  supplied  by  the  SEI.  These  are  used  to  produce  packages  called  field  and  record  typecasters  and  the 
definition  of  an  external  representation  of  the  message  called  ICD.  All  of  the  messages  produced  here  are 
Ada  reusable  code.  The  second  part  of  the  MTV  process  takes  these  models  and  joins  them  together  for 
particular  message  type.  This  is  an  Ada  package  linked  with  the  components  produced  above  to  execute 
the  translation  and  validation  of  a  message. 
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SPECIFIC  FUNCTIONS  WITHIN  THE  DOMAIN 


The  Generic  Command  Center  Architecture  (GCCA),  as  defined  in  the  PRISM  GCCA  report,  has  a 
requirement  for  a  MTV  component  which  does  message  translation  and  validation  of  character  and  bit- 
based  messages,  with  subsequent  updates  to  the  database  and  mission  application.  These  are  primarily 
fixed  format  messages,  although  variant  fields  and  fixed  repetitions  of  fields  are  included,  e.g.,  ROCC/ 
SOCC  and  Tactical  Digital  Information  Link  (TADIL)  messages.  Messages  with  highly  complex  and 
variable  structures,  e.g..  United  States  Message  Text  Format (USMTF)  messages,  are  not  included  under 
MTV,  but  are  handled  by  the  Automated  Message  Handled AMH)  component.  It  is  also  pan  of  inter¬ 
process  communications  within  a  local  area  network. 

DESCRIPTION  OF  SALIENT  FEATURESS 

Developers  in  other  domains  (e.g.,  intelligence)  where  a  need  to  translate  and  validate  messages  exist,  can 
understand  and  use  the  MTV  model  solution.  There  is  one  version  of  MTV  which  handles  either  character 
or  bit  based  messages,  based  on  user  input  at  the  time  the  component  is  launched.  The  MTV  will  perform 
its  functions  in  real  time,  keeping  up  with  the  input  message  traffic.  The  number  of  fields  in  the  messages 
and  wether  they  are  character  or  bit  based  will  influence  the  message  throughput.  Based  on  typical  message 
complexity,  MTV  will  handle  the  above  message  rate  for  either  character  or  bit  based  messaged  with  at 
least  15  fields.  The  SEI  MTV  has  been  used  successfully  by  Granite  Sentry  for  character  based  messages. 

The  SEI  MTV  uses  a  model  solution  that  can  be  used  in  a  system  to  convert  between  different 
representations  of  a  message.  These  messages  representations  can  be  character  based,  bit  based, 
internal(Ada  values),  or  the  ASCII  equivalent  of  the  message.  The  MTV  software  consists  of  a  set  of 
utilities  and  Ada  coding  templates.  An  MTC  coding  template  is  an  Ada  file  containing  incomplete,  ie,  non- 
compilable  code.  Each  template  includes  a  package  specification,  package  body,  and  a  test  procedure 
which  tests  the  functionality  implemented  by  the  completed  template.  The  templates  contain  planeholders, 
by  which  the  message  fields  and  the  ICD  are  defined  uniquely.  The  definition  of  a  message  field  requires  a 
typecasters  template.  The  field  type,  e.g.,  integer,  enumeration,  determines  the  particular  typecasters 
template  to  use.  The  definition  of  the  entire  message  requires  a  recorded  typecasters.  The  completed 
typecasters  requires  a  record  typecasters.  The  completed  typecasters  templates  are  compilable  Ada 
packages,  called  typecasters.  The  external  view  of  the  message  is  built  from  an  ICD  template,  where  the 
term  ICD  alludes  to  Interface  Central  Document.  The  message  type,  character  or  bit,  determines  the 
particular  ICD  template  to  use.  The  completion  of  this  template  results  in  a  field-by-field  description  of  the 
message  in  terms  of  size,  type,  separator,  bit  position,  etc.,  depending  on  whether  the  message  is  character 
or  bit  based.  The  completed  templates  are  compilable  Ada  packages,  called  I  CDs.  An  ICD  depends  on  the 
typecasters  packages  corresponding  to  the  message  fields  and  on  the  record  typecasters  package  that 
defines  the  message. 

TECHNICAL  SPECIFICATIONS 

SEI  MTV  currently  includes  message  typecasters  for  the  bit_based  message:  Surveillance 
The  PRISM  version  of  MTV  includes  message  typecasters  for  these  ASCII  messages:  e3a;  NUDET, 
Intercepter;  170  ROCC/SOCC.  The  April  MTV  component  was  written  partly  in  C  and  included  Sybase 
specific  SWL  commands.  It  was  then  converted  entirely  to  ADA  and  the  Sybase-specific  SQL  converted  to 
ANSI  SQL.  This  SQL  translation  required  the  development  of  the  Database  Broker  component.  MTV 
includes  the  typecasters  and  ICD  generated  from  the  SEI  MTV  templates  and  support  software,  and 
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wrapper  software  written  for  PRISM.  The  wrapper  software  includes  interface  software  to  DEC 
MessageQ(DMQ),  SQL  generation  software,  and  the  interface  to  the  Database  Broker.  The  SEI  MTV  is 
written  in  Ada  and  contains  no  proprietary  products.  It  was  developed  and  tested  on  DEC/VMS  with  the 
intent  that  it  could  run  on  any  platform.  However,  integration  testing  showed  that  some  of  its  functionality 
had  machine  and  compiler  dependencies. 

With  the  addition  of  some  wrapper  software  and  modifications  to  the  SEI  MTV  fulfilled  the  component 
requirements.  These  modifications  were  required  primarily  to  handle  machine  and  compiler  dependencies. 
The  wrapper  software  interfaced  the  product  to  other  GCCA  components  on  the  mission  application.  The 
UNIX  tools  were  found  to  be  general  purpose  enough  to  handle  very  complex  character  based  messages, 
but  could  not  handle  bit_based  messages.  The  use  of  these  tools  would  require  significant  software 
development. 

SUPPORT 

Software  produce  by  PRISM  program  at  Electronic  Systems  CenterfESQ,  Systems  and  Software  Design 
Center  (AVS) 

Capt.  Paul  Valdez,  PRISM  Deputy  Program  Manager:  617-377-3458 

PRISM 

ESC/AVSI 

Hanscom  AFB,  MA  01731-5000 
LICENSING  AND  AVAILABILITY 

The  SEI  MTV  product  was  written  by  the  Software  Engineering  Institute(SEI).  It  is  government  off-the- 
shelf  software  and  does  not  require  a  license. 


B-5 


TECHNICAL 


BRIEF 


Central  Archive  for  Reusable  Defense  Software 


INTRODUCTION/OVERVIEW 


OELSTOCK  is  a  high  resolution  interactive  graphics  system.  In  addition  to  data  display,  analysts  can  use  it 
to  draw  geopositional  overlays  on  OILSTOCK  maps  to  produce  reports  or  amplify  information. 
OILSTOCK  uses  the  CIA  World  Database  n  (WDBII)  as  its  foundation  for  vector  maps  and  the  Defense 
Mapping  Agency’s  ARC  Digitized  Raster  Graphics  for  high  quality  raster  maps.  OILSTOCK  reads  Digital 
Terrain  Elevation  Data  tc  conduct  a  visual  line  of  site  analysis. 

Application  Area 

OILSTOCK  is  accompanied  by  excellent  hard-copy  manuals,  which  make  installation  quite  easy.  The 
organization  makes  them  easy  to  use  as  a  reference  and  a  tutorial.  An  on-line  help  facility  is  also  available. 
It  is  recognized  that  the  specific  functionality  requirements  of  command  centers  for  their  spatial 
information  capabilities  vary  greatly.  Further,  given  the  realization  of  the  diverse  nature  of  the  different 
approaches  taken  for  packaging  GIS  and  mapping  system  components,  and  its  subsequent  evaluation,  it  is 
necessary  to  be  cognizant  of  these  differences  when  defining  the  evaluation  criteria.  Therefore,  the  tact 
taken  in  evaluating  such  systems  will  focus  on  a  very  small  set  of  core  or  critical  criteria.  Other  features  are 
examined  and  noted,  but  generally  deemed  non-critical  for  inclusion  into  the  CARDS  Command  Center 
Library.  It  is  then  left  to  the  library  user  to  examine  the  report  to  determine  if  a  particular  system  meets  the 
user’s  requirements. 

Limitations 

The  interface  is  somewhat  cumbersome  to  use  at  first,  although  it  becomes  substantially  easier  as  it  is  used 
In  some  cases  during  the  qualification  process  of  OILSTOCK  into  the  CARDS  Command  Center  Library, 
odd  projections  and  views  in  conjunction  with  user  defined  overlays  produced  some  unexpected  results.  It 
would  seem  some  defects  are  present,  but  it  was  easy  to  undo  the  defective  map  and  try  again  in  another 
manner.  No  other  anomalies  were  discovered.. 

DETAILED  FUNCTIONAL  DESCRIPTION 

OILSTOCK  uses  the  CIA  World  Database  II  (WDBII)  as  its  foundation  for  vector  maps  and  the  Defense 
Mapping  Agency’s  ARC  Digitized  Raster  Graphics  for  high  quality  raster  maps.  OILSTOCK  reads  Digital 
Terrain  Elevation  Data  to  conduct  a  visual  line  of  site  analysis.ODLSTOCK  also  supports  cartographic 
overlays  and  numerous  map  projections.  According  to  the  manual,  each  of  these  projections  exists  to 
support  different  human-based  analysis.  The  plots  and  overlays  are  adjusted  to  reflect  the  projection 
displayed.  For  example,  if  an  overlay  is  created  with  an  icon  of  the  Empire  State  Building  placed  on  New 
York  City,  then  scrolling,  zooming  and  changing  the  map  projection  does  not  affect  the  placement  of  the 
icon,  i.e.  it  is  still  on  New  York  City.  However,  the  size  of  the  icon  remains  constant.  Icons  may  be  placed 
by  latitude/longitude  specification  or  by  point  -  and-  click  mouse  interaction.  Icons  may  not  be  used  in  a 
target  plot.  Target  position  is  updated  via  messages  sent  to  the  OILSTOCK  system.  ASCII  files  in  a 
specified  format  can  also  be  used  to  display  tracking  information.  OILSTOCK  is  also  used  to  display 
tracking  information.  OILSTOCK  does  not  allow  either  on  demand  or  autonomous  DBMS  access. 

SPECIFIC  FUNCTIONS  WITHIN  THE  DOMAIN 

Oil  stock  is  designed  to  track  airborne  targets,  including  aircraft,  satellites,  and  sea  going  vessels.  In 
addition  to  data  display,  analysts  can  Draw  geopositional  overlays  on  OILSTOCK  maps  to  produce  reports 
or  amplify  information. 
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OILSTOCK  is  a  stand-alone  Geographic  Information  System  (GIS)  application  with  features  that  are 
present  to  better  visualize  and  evaluate  plots,  including  placement  of  icons,  range  rings,  etc.  onto  a  sketch 
pad  which  can  be  saved  to  a  cartographic  overlay,  and  draped  over  various  map  projections.OILSTOCK 
provides  a  mapping  system  application  with  support  for  analysis  of  target  plotting  It  is  easily  installed  and 
evaluated  with  the  help  of  well  written  manuals.The  various  map  projections  supported  by  OILSTOCK 
allow  numerous  views  of  plotted  data.  The  icons  are  already  defined  when  delivered.  Incorporation  of  new 
databases  is  described  fully  in  the  Oilstock  Installation  Guide  and  seems  to  be  relatively  uncomplicated. 
Advanced  features  include  ELINT/Direction  Finding  capabilities  and  calculating  satellite  footprints. 
OILSTOCK  also  supports  cartographic  overlays  and  numerous  map  projections.  OILSTOCK  reads  data 
from  a  large  number  of  data  formats,  including  the  CIA  World  Data  Bank  n  (WDBII)  and  Digital  Mapping 
Agency  (DMA)  digital  maps.  The  many  and  varied  GIS  and  mapping  system  commercial  and  government 
products  tak'  two  basic  approaches  to  how  they  are  packaged.  First  is  the  stand-alone  application,  where  a 
user’s  interaction  is  limited  to  a  graphical  user  interface  (GUI).  Other  systems  are  packaged  as  a  toolkit, 
where  the  functionality  of  the  system  is  available  to  the  user  via  application  programming  interfaces  (API) 
special  scripting  languages,  and  macro  construction,  which  can  be  used  in  concert  to  create  an  application. 
Most  often  it  is  a  hybrid,  usually  leaning  more  toward  the  stand-alone  system,  a  system  with  some 
flexibility  in  interaction,  but  functioning  primarily  as  a  single  stand-alone  application.  OILSTOCK  is  not  a 
GIS  tool-kit,  but  is  rather  a  completed  GIS  application  that  might  be  constructed  from  such  a  tool-kit. 
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OILSTOCK  was  developed  in  C  on  a  System  V  UNIX  machine,  using  X  windows  for  display.  It  was  also 
shown  to  work  properly  under  Motif  and  TWM.  These  latter  two  environments  were  not  as  thoroughly 
tested.  It  has  been  successfully  compiled  on  the  following  platforms:  Sun3,  Sun4,  Masscomp,  Apollo,  HP 
720,  Silicon  Graphics,  DEC,  IBM  RS/6000,  and  Data  General  workstations. 

SUPPORT 

Support  is  available  from  NSA  via  U.S.  mail  and  a  toll  phone  number: 

The  National  Security  Agency,  J333 
9800  Savage  Rd. 

Fort  Geoige  G.  Mead.  MD  20755 
(301)  688-5564 

OILSTOCK  is  accompanied  by  excellent  hard-copy  manuals. 
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OILSTOCK  has  been  released  to  the  CARDS  Program  for  Official  Use  Only  (FOUO)  by  the  National 
Security  Agency  (NSA).OILSTOCK  has  also  been  released  to  a  number  of  other  government  agencies  and 
contractors  under  the  same  restrictions. 


B-8 


STARS-VC-B013/001/00 


22  February  1994 


REFERENCES 


[1]  DoD  Domain  Definition  Report,  DoD  Center  for  Software  Reuse  Operations,  The  Defense 

Information  Systems  Agency/Corporate  Information  Management  (DISA/CIM),  May 
92. 

[2]  Huber,  Theresa  R.,  “Findings  of  the  CARDS  Sponsored  Software  Reuse  Legal  Workshop”, 

DSD  Laboratories,  Inc.,  Procedings  of  the  6th  Annual  Workshop  on  Software  Reuse 
(WISR93),  Owego,  NY,  2 A  Nov  93 

[3]  Library  Development  Handbook.  Informal  Technical  Repot  STARS-VC-B005,  29  October 

1993. 

[4]  Library  Operations  Policies  and  Procedures  for  the  Central  Archive  for  Reusable  Defense 

Software:  Update  -  Volumes  I,  n,  IE.  Informal  Technical  Report  STARS-VC- 
B 004/002/00,  B004/002/01;  \bl.  I  and  Vol.  D.  27  February  1994 

[5]  STARS  Reuse  concepts.  Volume  I,  Conceptual  Framework  for  Reuse  Processes  (CFRP), 

Version  2,  STARS-UC-05159/00100,  13  Nov  92. 

[6]  Poore,  J.H.  and  Theresa  Pepin.  “Criteria  and  Implementation  Procedures  for  Evaluation  of 

Reusable  Software  Engineering  Assets,”  ASSET  The  National  Software  Technology 
Repository,  March  1992. 

[7]  Technical  Concept  Document,  Central  Archive  for  Reusable  Defense  Software  (CARDS), 

STARS-VC-03536/001/00,  27  February  1994. 

[8]  Tracz,  Will.  “A  conceptual  model  for  megaprogramming,  “Software  Engineering  Notes, 

ACM  Press,  \*>1.  16,  Number  3  (July  1991). 

[9]  Wallnau,  Kurt  C.  CARDS  Libraries  and  a  Standard  DoD  Component  Classification  Scheme. 

Par  am  ax  Systems  Corporation,  February  1993. 


R-1 


